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BRIEFING OUTLINE 


i STUDY BACKGROUND 

• REVIEW OF SYSTEM CONCEPTS DERIVED FROM STUDY PHASE A 

• SYSTEM CONCEPT REFINEMENT DURING STUDY CONTINUATION^ PHASE A~1 

• STANDARD POCC IMPLEMENTATION 

• IDENTIFICATION OF JOINT ACTIVITIES AND ESTIMATION OF RESOURCES 

IN PREPARATION FOR JOINT OPERATIONS 


« OVERALL STUDY CONCLUSIONS AND RECOMMENDATIONS 
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STUDY BACKGROUND 


I 



STUDY 



PHASE A 

The goal of this study was to develop user oriented STS-Payload Mission Control 
concepts which provide for optimum contribution of ground flight control support to 
onboard capability to meet STS-Payload objectives in a cost-effective manner. The 
specific objectives are those listed on the facing page. 


CONTINUATION PHASE A-1 

The objectives of the Continuation Phase were to refine selective concepts 
from the basic study relative to POCC implementation and to identify the major 
joint activities required for flight preparation and estimate the joint resources 
necessary to accomplish these activities. 
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STUDY OBJECTIVES 


PHASE A 

• IDENTIFY FLIGHT CONTROL GROUND FUNCTIONS FOR REPRESENTATIVE 
STS PAYLOADS 

t INVESTIGATE PRESENT/pLANNED NASA-WIDE FACILITIES (CAPABILITIES) 
FOR STS PAYLOAD CONTROL 

0 DETERMINE FEASIBLE COST EFFECTIVE SYSTEM CONCEPT OPTIONS FOR 
FLIGHT CONTROL OF STS PAYLOADS 

• DEVELOP IMPLEMENTATION GUIDELINES FOR PROPOSED SYSTEM CONCEPT 
OPTIONS 

CONTINUATION PHASE A-1 

• REFINE CONCEPTS FROM BASIC STUDY INCLUDING: 

- APPROACHES TO POCC IMPLEMENTATION 

- DEFINITION OF INTERFACES^ PAYLOAD OPERATOR/STS FLIGHT 

OPERATOR 

• IDENTIFY JOINT PREFLIGHT ACTIVITIES AND ESTIMATE COMPOSITE 
JOINT RESOURCES 
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SCOPE OF STUOY 


PHASE A 

The scope of the Phase A Study was confined to the real-time operational concepts 
throughout the period from after OFT in 1980 through the fully mature operational phase 
extending through 1991. 

Interfaces between the STS Operator and Payload Operator were stressed and em- 
phasis was placed on determining the existing capabilities of the Centers for applica- 
tion to STS Payloads flight control. 

14 representative payload/flight types were selected from the three major classes 
of Spacelab, Automated Earth Orbiting and Planetary Payload. 


CONTINUATION PHASE A-1 

The Continuation Study Phase addressed the preflight planning, training and 
simulations activities beginning from L-2 years and extending to lift-off. 

The composite resources for the joint activities associated with preparations 
for flight operations were estimated during this study phase. 
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SCOPE OF STUDY 


PH .&aL-A 

• CONCEPTS FOR STS PAYLOAD REAL-TIME OPERATIONS 1980 THROUGH 
1991 

t INTERFACES BETWEEN STS PAYLOAD OPERATOR AND STS FLIGHT OPERATOR 

• EMPHASIS ON DETERMINING EXISTING NASA CENTERS CAPABILITIES FOR 
APPLICATION TO STS PAYLOADS 

§ 14 REPRESENTATIVE PAYLOAD FLIGHT TYPES FROM THREE CLASSESj 

SPACELAB, AUTOMATED EARTH ORBITING AND PLANETARY PAYLOADS 

CONTINUATION PHASE A-1 

• PREFLIGHT PLANNING AND FLIGHT PREPARATION INCLUDING TRAINING 
AND SIMULATIONS 

f ESTIMATION OF COMPOSITE RESOURCES FOR PREFLIGHT PLANNING^ 

, TRAINING AND SIMULATIONS^ 1978 THROUGH 1985 
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RELEVANT STUDY GUIDELINES 




The General Study Guidelines have remained essentially unchanged with the ex- 
ception of the Flight Traffic Model, which was updated by the COR as of 30 April 1976, 

The main thrust of this study effort will address STS Payload Programs during 
the operational STS Phase - 

The existing NASA capabilities, resources and modus operand! will be used as 
points of departure in performing this study. 

Flight support shall be provided in a manner which satisfies the requirements at 
minimum overall expenditure of resources. 

For on-orbit operations during periods when STS has an operational interface with 
the payload, "flight support" will be jointly provided by MCC/JSC and the responsible 
Payload Operations Center, ["Flight Support" here includes all functions (tasks) done 
in support of the on-orbit operations.] 

For on-orbit operations during periods when the STS has no operational interface 
with the payload, “flight support" will be provided by the responsible Payload Operations 
Center or Agent designated by the responsible payload project office. 
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RELEVANT STUDY GUIDELINES 


• STUDY EMPHASIZES OPERATIONAL ERA (AFTER OFT) 

• EXISTING NASA CAPABILITIES ARE POINT OF DEPARTURE FOR THIS STUDY 

t PROVIDE FLIGHT SUPPORT TO PAYLOADS WITH MINIMUM EXPENDITURE OF 
RESOURCES 


§ ON-ORBIT WHEN STS AND PAYLOAD INTERFACE OPERATIONALLY^ FLIGHT 
OPERATIONS SUPPORT IS PROVIDED JOINTLY BY MCC-H AND A POC 


• THE POCC HAS FULL RESPONSIBILITY FOR ITS PAYLOAD DURING FREE- 
FLIGHT 
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RELEVANT STUDY GUIDELINES 

(CDNTINUED) 


Payload organizations will utilize NASA Control Center host facilities for opera- 
tions or establish their own Payload Operations Centers where economically justified. 

Major NASA Control Centers shall provide host facilities for Customers, or pro- 
vide appropriate operational interfaces with Customers' remote location with respect 
to the Control Center, if feasible. 

A semi -automated "flight data base" shall be assumed. The "flight data base" 
need not be in one location so long as means for adequate transfer and interfacing 
of information between operations centers is provided. 

["Flight data base" is the reservoir of all data needed to plan or execute a 
flight, including system specification values, models, operating constraints, schedules, 
etc.] 


Simplicity of interfaces during launch/landing and during flight among user, 
developer and operator, and ease of total STS/STS Payload Ground System verification 
shall be considered as criteria in assessing interfaces and costs. 

The study will use the Flight Traffic Model provided by the COR on 30 April 1976 
and the same representative flight types and payloads. 


\ 


5 


RELEVANT STUDY GLMDEUNES 

(CONTINUED] 


• USERS UTILIZE NASA HOST FACILITY OR PROVIDE OWN OPERATIONS 

CENTER 

• MAJOR NASA POC'S PROVIDE HOST FACILITIES OR OPERATIONAL INTERFACES 

WITH CUSTOMERS 

• A SEMI -AUTOMATED "FLIGHT DATA BASE" SHALL BE ASSUMED 


• INTERFACE SIMPLICITY AMONG USER^ DEVELOPER^ AND OPERATOR^ AND 

EASE OF SYSTEM VERIFICATION ARE CRITERIA 

• STUDY USES UPDATED TRAFFIC MODEL PROVIDED BY THE COR AND SET OF 

14 REPRESENTATIVE PAYLOAD FLIGHT TYPES 
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STUDY TRAFFIC 


This STS Payload Traffic Model Chart combines the payload flight types selected 
for this study (including Spacelab, Automated Earth Orbit and Planetary) into a 
traffic model spread from 1980 through 1991. The traffic model presented was pro- 
vided by the NASA COR on 30 April 1976. The traffic rates approved for this study 
represent a reduced version (371 flights) of the 572-flight model approved for STS 
Operations Planning. 

This traffic model provides the basis for estimating composite resources 
required in preflight planning of flight operations, training and simulations. 
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FLI'GHT TYPE - PAYtfQAP 
DESCRaPTION 




H+P. HD - OTHER 

GSFC 

P ONLY, DC.'- SO 

GSFG 


P ONLY, DC - STELLAR 

GSFG 

P ONLY, MD - HEA, SEOPS, SO 

MSFG 

M ONLY, DO - LS 

JSC 


DELIVERY, MG - EXP, STP (!DOD) GSFC 


DELIVER - EOS GSFC 


DELIVER - ST' RETRIEVE HEAG-G I MSEC 


REVISIT W/0 EVA - EOS GSFG 


REVISIT VJ/EVA ‘- -ST M5FC 


DELIVER MC - BESS, SEOPS,, 2 MI1M-LAGEQS, ARC 
FFliO 


MS., m - OW, GOMSAT GSFG 


MS., TUG - Til, I'NTEL/SAT GSFC 


MARINER 


PIONEER 


SUBTOTAL, 7-DAY FLIGHTS 2 


SUBTOTAL, 30-D/^Y FLIGHTS 
(INCLUDES Ji) 


TOTALS 
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As can be seen from the adjolining schedule, the study began In January 1975 
and extends through December 20, T976., with the Gonttnuatlon Phase. 

The Study Schedule provided for periodic progress reviews and for the imcre- 
mental delivery of study documentation associated with each study task. 

There have been 20 separate study documents delivered in accordance with the 
documentation schedule listed at the bottom of the facing page. The total docu> 
mentation including the appendices to the Task C Final Study Document, Gontaims 
1650 pages of published study results. 
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The adjacent chart shows the Tnitial Ifstling of POG alternatives from which the 
concepts for STS Payload Flight Control were selected. 

These alternatives were based on the fonowing precepts; 

a. Utilization of an existing single P0G for each class of STS Payloads; 
Automated Earth Orbiting, Planetary and Spacelab Payloads, respectively. 

b. The use of multiple POG's for each class of STS Payload. 

e. An alternative tn which each NASA Payload Development Center has its 
own POG for flight control of its payloads. 


This matrix of options was used as a point of departure for the development of 
system concepts. 
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CONCEPT OPTION NO. 1 


The concept option shown in the adjacent diagrafn has the following features: 

a. It meets initial requirements for control of STS-Payloads at minimum 
eost. 

b. It makes maximum use of Centers' existing capabilttles and experienee. 

e. It requires minimum changes to the present mode of payload operations. 

k It provides a solid baseline for future expansion and for system en- 
hancements 

e. It will provide for easy transition from present payload operations to 
STS'Payload operations. 
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I ^ Conc^t Option Na, 2 contains the fblliowing additional features beyond those of 

I Option No« 1. 

I ■ ■ . ■ • ^ ■■ ■■" ' 

P : ■ T: ■ J ■ ^ ^ ^ / 

p: _ ^ ^ a. A Payload Ooordlhator has been added to doordinate payload operations with- 

I in each class of payloads. This reduces the number of operational Interfeces 

I : between the STS Operator and the payload projects when problems arise tdiich 

affect STS Joint Operations requiring resolution among the payload pro- 
■ jects. 

r.' • - • ■ ■' 

I • 7 ' ^ - . ■ . ■ . ■ . . ' • ^ 

I b. A higher level of standardization of operational procedures among the pay- 

I loads of a given class can be achieved with this concept, 

H-' ■ ■ • 

••• 

r • ■ ■ ■ • • 

I c. Increased versatility for Spacelab and AEG Payload operation is achieved. 

F ' • ■ ’ ■ ' ' 

I V ■. /-■ ■ r- '■ :■ ■ ■; ■ ■■ ■ . ■■ . . - , 

U' . ■ ' ■■ ■■ ■■■ " ■ I ^ ' . ' ' ■ ' ■ 

ife' ■ 
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JOINT STS-PAYLOAD 
FLIGHT CONTROL SYSTEM 
CONCEPT OPTION NO. 3 


System ConGept Option No. 3 is envisioned for the period of mature STS Operations 
when the Payload Traffic Model reaches its maximum level of activity. Hie additional 
feai^ures of this concept include: 

a. It provides for use of efficient remote POCC's. 

b. It operates in conjunction with an integrated network control (System NOCC)^ 



i; c. The addition of an Integrated Operations Manager (lOM), presents a single 

standard payload interface to MCC-M, System NQCC and the Launch/ianding 
^ Sites for resolution of certain payload problems. 

d:. It accommodates standard operational procedures/conventions in an optimum 
way. 
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The faefng chart is a matrix which suirDnarlzes the comparative features of the 
three system concept options. 

It should be noted under the col umn ’'Payload - STS Operati ons Interface" , that 
POCC's always handle their day to day routine operational matters directly with other 
operational elements. The PC's and the lOM do not become involved in routine day to 
day operations. They resolve problems which develop at a higher level and which in^ 
volve more than one payload. 


The last column provides an indication of the system impli cat ions imposed by 
each of the vairious concept options. System Implications, are those matters which 
interact with more than one NASA Center or which involve the networks, communications, 
or other resources which impact all of the centers. 
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COMPARaDN OF CONCEFT 
OPTION FEATUFIES 


CONCEPT 

OPTION 

PAYLOAD CLASS 
SUPPORT 
CAPABILITY 

PAYLOAD - STS 
OPERATIONS 
INTERFACE 

POCC 

TYPE 

SYSTEM IMPLICATIONS 

No. 1 

GSFC - AEO 
JSG— SPAGELAB 

JPL - PLANETARY 

DIRECT; INDIVIDUAL 
POCC'S TO OPERATIONAL 
ELEMENTS 

DEDICATED. 

NEW POCC'S FOR SPACGUB 
SHOULD BE DESIGNED FOR FUTURE 
STANDARDIZATION WITH OTHER 
POCC'S 

No,. 2 

6S FC - 
PRI : AEO 
BACKUP: SPAGELAB 

JSG - 

PRI: SPAGELAB 

BACKUP: AEO 

JPL - 

PRI : PLANETARY 

DIRECT FOR ROUTINE 
OPERATIONS. INDIVIDUAL 
POGG'S TO OPERATIONAL 
ELEMENTS. 

P.G. TO HANDLE PROBLEMS 
AFFECTING MULTIPLE 
PAYLOADS OF A CUSS, 

LIMITED 
STANDARDIZA- 
TION. STD FOR 
JOINT OPS. 
UNIQUE MODULES 
FOR FREE- 
FLVERS 

PAYLOAD DESIGN STANDARDS. 
COMMUNICATIONS SYSTEMS 

STAMDARnR 

STANDARDIZED USER INTERFACES. 
POCC OPERATIONS STANDARDS. 
SUPERVISORY DATA BASE SYSTEM. 

No. 3 

GSFC - 
PRI: AEO 
BACKUP: SPAGELAB 

JSG - 

PRI : SPAGELAB 

BACKUP: AEO 

JPL - 

PRI: PLANETARY 

LIMITED 

BACKUP: SPAGELAB & AEO! 

DIRECT FOR ROUTINE 
OPERATIONS. INDIVIDUAL 
POCC'S TO OPERATIONAL 
ELEMENTS. 

P.C. TO HANDLE PROBLEMS 
AFFECTING MULTIPLE 
PAYLOADS OF A CLASS. 

lOM TO HANDLE PROBLEMS 
AFFECTING MULTIPLE 
PAYLOAD GLASSES. 

LIMITED STAN- 
DARDIZATION. 

STD FOR 
JOINT OPS. 

UNIQUE MO- 
DULES FOR 
FREE-FLYERS 

STANDARD POR- 
TABLE POCC’S, 

STANDARD DATA PROCESSING AND 
OPERATING SYSTEMS.. 

DOMSATS FOR WIDEBAND COMM. 

INTEGRATED NETWORK CONTROL. 

SYSTEM OPERATING STANDARDS. 


















The Payload Coordinator should reside at each Payload Operations Center and coor 
dinate external STS operational problems for all payloads of a given class. 

The PC will coordiinate between POCC's and Centers when conflicts in the use of 
resources arise. 

By parti cipatling in operational planning, the PC can help to insure standardiza- 
tion of operational procedures from pay load- to- payload or flight- to- flight. 

He provides a single point contact with the lOM or the STS Operator for resolu- 
tion of problems within a payload class. 

He resolves conflicts of resources between payload programs. 

Where contingencies arise which affect two or more payloads, the PC can assist 
in the resolution of these matters. 

Thn PC will have a staff which maintains the schedules and status of all opera- 
tions within a given payload class. 
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• FUNCTION RISIDES AT POC FOR EACH PAYLOAD CLASS 

• COORDINATES OPERATIONS BETWEEN CENTERS AND POCC'S FOR ALL PAY- 

LOADS OF A GIVEN CLASS 

• INSURES STANDARDIZATION OF OPERATIONS FROM FLIGHT TO FLIGHT 

• PROVIDES SINGLE POINT INTERFACE WITH STS OPERATOR FOR 

PAYLOAD CLASS 

• RESOLVES CONFLICTS OF RESOURCES REQUIREMENTS BETWEEN PAYLOAD 

PROGRAMS 




• ASSISTS IN RESOLVING GONTINGENCIES AFFECTING TWO OR MORE 
PAYLOADS 

f MAINTAINS SCHEDULE AND STATUS OF ALL OPERATIONS OF A GIVEN 
PAYLOAD CLASS 
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FUSCTICMMS OF THE PAYLOAD 
INTEGFIATED OPEFIATIONS MANAGER 

dOM] 


The I0M is located at JSG and represents the payload world. 

He provides the iinterface between the Payload Operators and NASA Headquarters during 
the real-time operation. 

He assures that the STS Operator obtains the necessary assi stance from payload pro- 
jects during integrated flight planning and he monitors the integrated flight plan during 
execution. 




f LOCATED AT JSC BUT NOT ORGANIZATIONALLY ATTACHED 

• PROVIDES THE REAL-TIME PAYLOAD OPERATIONAL INTERFACE WITH NASA HEADQUARTERS 
t ASSISTS STS FLIGHT OPERATOR IN INTEGRATED FLIGHT PLANNING 


• MONITORS INTEGRATED FLIGHT PLAN DURING EXECUTION 
§ RESOLVES CONTINGENCY OPERATIONS BETWEEN PAYLOAD CLASSES 


f INSURES STANDARDIZATION OF PROCEDURES AND FORMATS FOR OPERATIONAL INTER- 
FACES OF ALL PAYLOAD CLASSES 


• RESOLVES CONFLICTS OF REQUIREMENTS BETWEEN PAYLOAD CLASSES DURING REAL- 
TIME OPERATIONS 


• MAINTAINS SCHEDULE AND STATUS ON ALL PAYLOADS AND ASSESSES IMPACT OF 
REAL-TIME OPERATIONAL CHANGES ON OTHER SCHEDULE OPERATIONS 
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In order to make maximum use of existing NASA capabilities, an evolutionary approach 
to an integrated standardized multi- center system of PQGG's is necessary. The implementa- 
tion plan to achieve such standardization should account for the normal wear out cycle of 
existing systems and phase-in standardized replacements in an orderly fashion. 

A system involviing standard PQGG's with the capability to support any payload on a 
quick tum-around basis will provide a higher utilization factor for POGC's and reduce 
the total number of PQGG's required for STS payload support. 

If the concept of standard PQGG's is adopted it will be necessary to establish early 
requirements for payload operational standards. This requirement should be phased in 
gradually over a considerable period of time so as not to impact payload designs presently 
under way. At the same time, standards should be defined early so as to permit NASA to 
negotiate them into new payload designs during the fomulative stages of the various pro- 
grams. 

A key decision to be made as early as possible is whether to expand the capabilities 
of the three baseline centers to support all payloads or augment the capability of addi- 
tional centers to support the increasing load during later phases of the STS Payload era. 

A major stride in system enhancement for the users will be the introduction of por- 
table POGC/DOMSAT Terminals to provide wideband communications and control capability for 
remote users or additional centers as an extension of the POGG at one of the baseline centers 
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• AN EVOUJTIONARY APPROACH TO AN INTEGRATED^ STANDARDIZED MULTI- 

CENtER SYSTEM FOR FLIGHT CONTROL OF STS PAYLOADS IS INDICATED 
DURING JOINT STS PAYLOAD OPERATIONAL FLIGHT PHASES. 

• THE ULTIMATE SYSTEM PROVIDES REASONABLE STANDARDIZATION OF POCC'S FOR 

ALL PAYLOADS. 

• AN EARLY PROGRAM IS NEEDED TO ESTABLISH STANDARDS FOR STS 

PAYLOADS. 

t AN EARLY KEY DECISION NEEDED IS WHETHER TO EXPAND THE TRI- 
CENTERa GSPC/jSC/jiPL/ SYSTEM OR EQUIP ADDITIONAL CENTERS. 

• A PORTABLE^ INTERACTIVE POCC DOMSAT TERMINAL APPEARS TO BE A 

PRAGTICAL MODE OF OPERATION FOR SIPECIFIC USERS. 


I6a 
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To determine the extent to which a Standard POGG would be practical , all fl ight con^ 
trol functions for the 14 payload/ fl ight types were reviewed to determine which could be 
handled in a standard manner from payload to payload and which would require unique sup- 
port from a POGG. 

Following this a series of conceptual POGG design configurations were examined. The 
result of this effort was a functional modularized POGG architecture Whiqh allowed the 
hardware and software to be assembled in functional modules. 

The study team reexamined the initial approach to a fully Standard POGG implementation 
to develop a more practical implementation leading to an optimally Standard POGG which 
could interface with non-standard user modules via a standard Interface approach. 
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• REVIEWED PAYLOAD FLIGHT CONTROL FUNCTIONS IN DETAIL FOR 
ADAPTABILITY TO STANDARD VERSUS UNIQUE POCC SUPPORT 


• INVESTIGATED POCC STANDARDIZATION CONCEPTUAL DESIGN 
ALTERNATIVES 


DEVELOPED CONCEPTUAL POCC FUNCTIONAL ARCHITECTURE 


• REEXAMINED IMPLEMENTATION APPROACH TO A GOST EFFECTIVE 
EVOLUTIONARY SYSTEM TO ACHIEVE REASONABLE LEVEL OF POCC 
STANDARDIZATION 


1:8a 






Steps similar to those taken by GSFG to develop the Multi-mission Modular Spacecraft (MMS) 
should be extended to all classes of payloads at the earliest practical time. This would 
make standardization of ground flight control systems much more easily achieveable and 
would reap large benefits in cost savings. 

Another major cost savings will occur when new schedules are effective for Domestic 
Satellite Midland ComnunlGations such that large quantities of data can be transmitted 
point to point in real-time. 

A supervisory data base management system Is necessary to insure that STS-Payload 
data is maiintained current, that vmnecessary redundancy is eliminated and that data can 
be rapidly accessed from one system element to another. 

Once the Standard POCC is a reality, there will be a need for a single central authority 
for control of all MASA tracking and data acquisition resources. 

Operations will be greatly simplified if POCC's all utilize standard operational 
interfaces wi th other STS operational elements such as the MGC-H, Launch and Landing Sites, 
Networks, Users, and the various science and engineering support teams supporting the pay- 
load operations. 
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§ EARLY IMPLEMENTATION OF PAYLOAO STANDARDS AMD CONVENTIONS 
REQUIRED 

• LOW COST POINT TO POINT COMMUNICATIONS 

• DIRECT COMPUTER TO COMPUTER COMMUNICATIONS BETWEEN POC'S 
§ SUPERVISORY DATA BASE MANAGEMENT SYSTEM 

• INTEGRATED NETWORK OPERATIONS CONTROL CENTER (NOCC) 

• STANDARD EXTERNAL INTERFACES FOR POCC'S WITH 

- MCC-H 

- launch/landing sites 

- NETWORKS 

- USERS 

- SCIENCE ANALYSIS SUPPORT TEAMS 

- ENGINEERING ANALYSIS SUPPORT TEAMS 


\ f 
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The dhart on the fading page shows on a general scale, the extent of standardization 
versus uniqueness achleveable for each of the selected POCC functions which were Inves- 
tigated. 


For example, the processing of data can be done to a very high degree of standardi- 
zation in aGcordance with prior instructions, although It is recognized that the analysis 
of processed data may be hiighly unique and may have to be done off-line by highly special- 
ized personnel . 

Functions such as comnuniicatlons processing, data base management, man/machine 
Interfaces, system test and checkout, system flight control and payload telemetry and 
command processing can be made to have a high degree of similarity in their methods of 
handling within a POCC. 


Conversely, some functions such as simulation and training, mission planning, pay- | 

load operations and control, and experiment operation and control will always have a ; 

high content of unique or mission peculiair characteristics. j 

- ] i 

U i 
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RJNCTHDNAL 

STANDARDIZATiaN ANALYSIS 


INVESTIGATED AS 
VERSUS UNIQUE 


100 %- 


DATA PROCESSING SYSTEM 
SOFTWARE 

COMMUN 1 CAT IONS PROCESS I NG 

DATA BASE MANAGEMENT 

MAN/MACW I NE I NTERFACES 

SIMULATION AND TRAINING 

SYSTEM TESTING AND PREFLIGHT 
CHECKOUT 

MISSION PLANNING 

FLIGHT CONTROL (sYSTEM) 

PAYLOAD'S OPERATIONS AND 
CONTROL 

PAYLOAD COMMAND PROCESSING 
TELEMETRY DATA PROCESSING 

(rt) 

EXPERIMENT OPERATION AND 
CONTROL (rt) 






The chaiPt shows three alternatives for implementing various levels of standanrdiza- 
tion among the POCG's for each eenter. 

f 

The first column depicts a set of dedicated POCC's for each Center where all PGCC's 
of a given Center would have standard capability to which the necessary unique capabilities 
would be added to accommodate the special requirements of the individual payloads. within 
tile class of payloads supported by the PQCG's. 

The second column depicts limited standardization where each Center has Standard 
!j P0GG's for all standard functiions and where 6SFG and JSG have unique but identical support 

I modules to support the non-standard functions of both classes of payloads. JPL only, would 

I have the eapabillty to support the unique Planetary Flight Gontrol functions. 

I The third column shows the concept of full standardization where each Center would 

Pi- 

I have identical standard POCC's with a full range of capabilities to support the unique 

I functions of any class of payloads. 

I The concept of limited standardization in the center column is the recomnended 

I approach. 
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GC3NCEPT OF LIMITED 
STATOAFIDIZATION WITH BACKUP 

CAPABILITY 


Following an tn-de|>th analysis of all the flight oontrol functions which were in- f) I 

I " I 

terpreted for ground control by the Payload Operator at the POGC's, It was concluded that t 

limited standardization with some backup capability among the POGC's was the optimum I 

solution. ‘Li ) 



The facing chart shows the concept of full backup capability between GSFG and JSC 
for Spacelab and Automated Earth Orbiting POGC's and backup by JPL for the Standard POCG 
functions in support of both AE0 and Spacelab Payloads. Because of the unique character- 
istics of Planetary Flight Control, it was not considered feasible for JSC or 65FG to 
backup JPL in the control of Planetary Payloads . 
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ANALYSIS RESULTED IN CONCLUSION THAT LIMITED STANDARDIZATION WITH 
BACKUP CAPABILITY IS OPTIMUM SOLUTION 


POC'S 

SPACELAB 

AEO 

PLANETARY 

GSFC 

FULL BACKUP 

PRIMARY 


JSC 

PRIMARY 

FULL BACKUP 


JPL 

LIMITED BACKUP 

LIMITED BACKUP 

PRIMARY 


NOTE: FULL BACKUP CAPABILITY BETWEEN POCC'S OF ANY SINGLE 

POC 
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FUNCTIONAL BLOCK DIAGRAM 


Tihe Functional Block Diagram shows the functions of the Standard POCG in terms 
of system support functions and real-time operational functions. Since the off-line 
function of mission planning interacts with the Standard POGC functions, it is shown 

interfacing through the POGG Data Base and the real-time operational control functions. 


It will be noted that Flight Gontrol, Payload Operations Control and Experiment 
Operation Control are listed separately. These distinctions have been made in order 
to categorize functions into standard groupings regardless of the class of payload, 
i.e. , Spacelab, or Free- Flyers. 

Flight Control Functions pertain to the Spacelab or a Free- Flyer Spacecraft. 

An example would be an orientation maneuver. Payload Operational Functions apply to 
the Payload or composite group of experiments. An Experiment Operation Control Func- 
tion would pertaiin to a silngle experiment or science package. 

The support functions include the Man/Machine Interface, Data Base Management, 
Communications Processing, Status Monitoring, Simulation and Training- All functions 
are under the control of the Data Proeessiing Operating System. 
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INTERPAONG 

AND nl 

OPERATING REMOTE POCC'S 

, , I] I 

I 

This chart identifies the conceptual capabilities for interfacing and operating the p- t 

■ ^ (I 

Ranote POCG'S. L j 

^ ^ ^ ^ ■ f 

Remote POGG's can provide the same full capability as a POGG located at the PGG or p | 

can provide any portion of the full eapabilities as a particular application may require. | 

Operational location of a Remote POGG is not a limiting factor as it is planned to q | 

provide for either two-way land lines or DOMSAT communications with the FOG or a cotiH L | 

bi nati on eonsi sting of transmitting by land lines and receiving by DOMSAT. ^ i 

R©nots POGG's always operate through the Parent POG or as an extens1<on of a POGG. ^ 

Additional support to Remote POGG's can be provided by the Parent POG consisting H f 

of payload health and/or science telemetry processing and/or command generation and ; 




f 


REMOTE POec'S ARE MODULAR AND MAY HAVE FULL OR PARTIAL 

capability 




• CAPABILITIES INCLUDE 

- DATA PROCESSING AND DISPLAY 

- PAYLOAD COMMAND PROCESSING 

- COMMUNICATIONS 

• REMOTE POCC'S MAY BE LOCATED ANYWHERE AND MAY BE INTER- 

FACED VIA; 

- LANDLINES 

- DOMSAT LINKS 

t REMOTE POCC OPERATIONS: 

- ALWAYS WORK THROUGH PARENT POC OR AS AN EXTENSION OF A POGC 

- WILL BE COORDINATED BY PAYLOAD COORDINATOR FOR 

OPERATIONS WITHIN A PAYLOAD CLASS 

- MAY RECEIVE ADDITIONAL SUPPORT FROM LOCAL POCC'S 

- MAY PROVIDE SUPPORT FOR SCIENCE ONLY OR COMPLETE 

PAYLOADS 
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POCC IMPLEIVENTATION 


The six major drivers for Standaird P0GC iimpliementation as listed on the facing pages are: 


1 . Cost 


2. Flight Rate Build- 
Up 


3. Increasing Numbers 
of Flight Overlaps 


4. Common Payload 
Interfaces With 
Mce-H 


5. Accommodatiion of 
Spacelab Payloads 


6. Increasing User 
Involvement 


Minimum cost dictates the use of existing facilities for as long as 
possible. Cost will also be miiniimized by standardization and as new 
systems are phased in., standardization can be achieved. 


As the traffic model builds toward peak levels the system capabilities 
should expand to accommodate the load. Based on the traffic model* the 
logical time phased support capability would seem to be 1980 for the 
initial capability building toward mid- 1983 for implementation of the 
Standard POGG concept with the necessary versatility to cope with 
rapidly increasing work loads after that poiint in time. 


Mbst flight overlaps occur with Planetary and Large complex free- flyer 
payloads. As overlaps build up* the requirements on data handling 
capacity and team structures will increase. 


The focal point during certain flight phases for an increasing nuirtber of 
operational functions will be the interface with MCG-H. Simplification 
and Standardization of interfaces and operating procedures will minimize 
thi s impact. 


Spacelab payloads will be the largest single class of payloads to be 
accommodated. Since these payloads are all short duration (7-30 days), 
the POGG systems at the various centers should be capable of spacelab 
payload support with quick turn-around times. Standard POCC's would 
facilitate this concept. 


As POGG's become more standard* versatility will increase. This will 
permit a more diverse set of user requirements to be met and with the 
incorporation of remote POGG's the user can be integrated into the NASA 
operational environment from his parent facility location. 
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§ COST DRIVES TOWARD USE OF EXISTING GAPABILITIESy 

STANDARDIZATION OF SYSTEMS AND PROCEDURES J 
SYSTEM VERSATILITY. 

f FLIGHT RATE BUILD-UP SUGGESTS TIME PHASED IMPLEMENTATION; IMPROVED 

SYSTEM TURN-AROUND TIMES; ENHANCED DATA 
HANDLING CAPABILITIES. 


. • INCREASING NUMBERS OF 
FLIGHT OVERLAPS 


CONSIDERATION FOR MULTIPLE RESOURCES FOR DATA 
HANDLING^ COMPUTATION AND TEAM STRUCTURES. 




COMMON PAYLOAD CONTROL 
INTERIFACES WITH MGC-H 


DRIVES TOWARD STANDARD OPERATING INTERFACES 
AND PROCEDURES. 


• ACCOMMODATION OF 

SPACELAB PAYLOADS 


SiPACELAB PAYLOADS TO BE LARGEST SINGLE CUSS^ 
ALL SHORT DURATION. ALL POCC'S SHOULD BE 
CAPABLE OF SPACELAB PAYLOAD SUPPORT. 


• INCREASING USER 
INVOLVEMENT 


GREATER POGC VERSATILITY. GEOGRAPHICAL DI- 
VERSIFICATION. 
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implehewtatiom rationale 

An evolutionary Implementation scheme should be Gonsidered to meet imitial require- 
ments at mn'nimum cost and to increase the STS Payload operations capability ahead of the 
expanding requirements. The suggested approach is to start with Concept No. 1 and grow 
towards Concept No.'s 2 and 3 as system loading iincreases. This iimplementation approach 
to meet the ultimate requirements can be made most cost effective by increasing the 
efficiency of early system elements rather than adding new elements. This may be achieved 
thirough such measures as: 

a. System standardization. 

b. Improved utilization of facilities and equipment. 

c. Added versatility for POCG's to support different payloads. 

d. use of firmware instead of software. 

e. Integration of separate functions performing similar tasks. 
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IMPLEMENTATION RATIONALE 

t START WITH EXISTING SYSTEM., CONCEPT NO. 1 

• GROW TOWARDS CONCEPTS 2 AND 3 AS SYSTEM LOADING DICTATES 

• EMPLOY A TIME PHASED BUILDING BLOCK APPROACH 

• MINIMIZE COSTS BY INCREASING SYSTEM EFFICIENCY THROUGH: 

STANDARDIZATION 
MODULARIZING POCC FUNCTIONS 
IMPROVED UTILIZATION 
POCC VERSATILITY (FAST TURN-AROUND) 

FIRMWARE VERSUS SOFTWARE 
INTEGRATION OF SEPARATE CAPABILITIES 

• A PRACTICAL APPROACH SUGGESTS EVOLVING FROM PRESENT SYSTEM 

TOWARD A FULLY INTEGRATED, MULT I -CENTER SYSTEM FOR STS- 
PAYLOAD SUPPORT 





Through the use of Domes tic Satellite links, either via Remote POCC's or via the POCC 
Gommumcatiing directly with a DOMSAT Ground Terminal, the real-time transfer of wideband 
data will greatly enhance the functions shown on the chart. 

Providing standard modular operatiing consoles for siimilar functions at each Center, 
such as those listed on the chart, will not only result in cost savings for the purchase 
and <9ieintenance of the consoles, but standardization of training and operating procedures 
will greatly benefit the personnel associated with these functions. 
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PROVIDE WIDEBAND DATA TRANSFER VIA DOMSATS TO ENABLE; 

- LEVELING COMPUTER LOADS BETWEEN CENTERS 

- REAL-TIME DISPLAY TRANSFER 

- DATA BASE INFORMATION EXCHANGE 

- HIGH SPEED DATAFAX HARD COPY EXCHANGE 


PROVIDE STANDARD MODULAR OPERATING CONSOLES FOR SIMILAR 
FUNCTIONS AT EACH CENTER 

- STANDARD SPACE FLIGHT GONTROLLERS CONSOLE 

- STANDARD COMMUNICATIONS CONSOLE 

- , STANDARD SYSTEM CONFIGURATION CONSOLE WITH 

REMOTE POCC INTERFACE MODULE 

- STANDARD COMMAND CONSOLE 

- STANDARD DATA PROCESSING AND DISPLAY CONSOLE 

MODULES^ SUCH AS : 

PAYLOAD WEALTH TELEMETRY MODULE 
PAYLOAD SCIENCE TELEMETRY MODULE 
PAYLOAD STATUS AND ALARM PANEL 
PAYLOAD (SPACELAB) CREW MONITOR MODULE 
PAYLOAD GUIDANCE AND NAVIGATION MODULE 
PAYLOAD CONSUMABLES MANAGEMENT MODULE 
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The standardization of payload data processing, stripping,, formattiing and routing,, 
should be accomplished in accordance with User requirements by designated resources. 
This will not only accelerate the Gonrounication of payload data to the user, but will 
expedite emergency control or orbiting and operating payloads. 

Functional support for Standard POCC's for the functions listed should be provided 
either by the parent POG associated with the POGG or via designated functional support 
elements within the NASA System, 

Because of the projected multi-overlap of satellites operating after the 1982 era, 
the necessary POGG redundancy sufficient to support multiple missions without mutual 
interference should be implemented at each POGG. 

System architecture should maximize the use of mini -computers in order to provide 
flexibility and simplify rapid reconfiguration of a POGG from one mission to another. 
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§ ALL PAYLOAD DATA PREPROCESS I N6^ STRIPPING^ FORMATTING AND ROUTING DONE BY 
DESIGNATED DATA ACQUISITION RESOURCES^ PER USER REQUIREMENTS 
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• CENTRAL I ZED FUNCTIONAL SUPPORT FOR STANDARD POCC'S WHERE MAJOR RESOURCES 

ARE REQUIRED 

- VIDEO AND WIDEBAND ANALOG PROCESSING 

- FREE-FLYER EARTH ORBITING TRAJECTORY ANALYSIS AND ORBIT DETERMIN- 

ATION 

- PLANiETARY PAYLOAD TRAJECTORY ANALYSIS AND COMPUTATION 

- SPACELAB TRAJECTORY ANALYSIS AND COMPUTATION 

- DISTRIBUTED DATA BASE SYSTEM UNDER SUPERVISORY CONTROL OF SINGLE 

CENTER 

• POGC'S SHOULD CONTAIN ENOUGH REDUNDANCY TO SIMULTANEOUSLY SUPPORT ONE SHORT 

JOINT MISSION AND ONE OR MORE LONG DURATION FREE-FLYERS WITHOUT MUTUAL 
INTERFERENCE 




• POCG ARCHITECTURE SHOULD UTILIZE MIN I -COMPUTERS FOR SEPARATE FUNCTIONS IN 
ORDER TO: 

- ELIMINATE THE PROBLEM OF MAINTAINING LARGE COMPLEX SOFTWARE SYSTEMS 

- FACILITATE CUSTOMIZED USER INTERFACES 

- SIMPLIFY POCC INTEGRATION AND PERMIT RAPID RECONiFIGURATION 
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This chart shows a summary of the development activity and the interactions between 
activities on a timeliine extending from 1977 through Mid*-T982. 

The major thrust of the recommended POCC iimplementatiion plan is to reduce ground 
operating costs through an evol uttonary implementation of flexible standard systems of 
hardware and software for PQCC's to be implemented as replacements at the time of the 
normal equipment generation update period. 

The 1977-78 activities involve a detailed requirements defimition in parallel with 
a cost analysis to assess the savings which can result from the Standard POGG approach. 
It is anticipated that the cost analysis will justify the continued efforts. 

The bars extending from 1979 through Hld-1982 depict the implementation phase and 
show the span of activities for POGC's of each Center (JSG, GSFC and JPL), as well as 
the span of activities for achieving the iintegrated system of POGC's. 

At the bottom right, the overlapping blocks indicate the general time phasing 
for augmenting or upgrading the various systems and functions leading to an iintegrated 
NASA-wide system of POGC's. 
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In suimiary, the major features of the Standard POCC approach are: 

a. To iintegrate the necessray resources from all three Centers into an over- 
all system for support of STS-Payloads. 


b. 


To follow an evolutlonairy implementation scheme where the best features 
of each center are retained and enhanced as necessary to formulate a 
standard Implementation for all centers. 


c. To limplement standardization only to the extent practical and to care- 
fully examine the gains resultlmg from each new step in the direction 
of standardization versus the retention of specific unique capabilities. 


31 






^ ‘ ^ V r -'i .V : k' ■ 


rvfj IV' wi !■ tv p /y?-nj*.<r 






MAJOR 









• INTEGRATE RESOURCES FROM THREE CENTERS INTO OVERALL SYSTEM 
OF STANDARD POCC'S 


t EVOLUTIONARY IMPLEMENTATION SCHEME 

CONCEPT 1 CONCEPT 2 CONCEPT 3 

RESULTING IN A GRADUAL PHASE-OUT OF EXISTING SUBSYSTEMS AND 
PHASE-IN OiF NEW SOFTWARE^ HARDWARE AND PROCEDURES 


• PARTIAL STANDARDIZATION RECOMMENDED — I.E., JSC^ GSFC AND 
JPL CAPABLE OF HANDLING ANY SPACELAB PAYLOAD^ GSFC AND 
JSC^ ANY AEO PAYLOAD AND JPL^ ANY PLANIETARY PAYLOAD 
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The following guidelines apply for identifiGation of joint activities and resources estimation. 

a. Only those activities that involve joint participation of STS and Payload organizational 
elements are addressed. 

b. The activity period addressed in this part of the study is limited to the pre-launch per- 
iod from two years before launch through conmittment for launch, just prior to lift-off. 

c. The study addresses Operational-Era Flights only, defined as all flights after six Orbital 
hight Tests (OFT's), i.e., period 1980-1991, however, resources are estimated only through 
1985 Flights. 

d. The study addresses preparations for Flight Operations only (including flight planning, 
traiining and simulations), but does not address Ground Operations at the Launch and Land- 
ing Sites. 

e. An "assembly-line" approach will be followed when appropriate, whereby interactive activi- 
ties accomplished iinteiractively on each flight will be repeated with same people flight- 
to-flight and payload-to-payload. 

f. Personnel included in the activity man-loading estimates of Task 3 are professional per- 
sonnel only, from all neGessary organizations/functions involved in the joint tasks, 
rounded to the nearest iinteger. 
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f ONLY JOINT ACTIVITIES ADDRESSED IN STUDY 

• PERIOD OF ACTIVITY^ L-2 YEARS TO LAUNCH COMMIT 

t OPERATIONAL ERA FLIGHTS - AFTER OFT THROUGH 1991, RESOURCES 
ESTIMATED ONLY THROUGH 1985 FLIGHTS 

t STUDY ADDRESSES PREPARATIONS FOR FLIGHT OPERATIONS^ NOT GROUND 
OPERATIONS AT LAUNCH/LANDING SITES 





t AN "ASSEMBLY LINE" APPROACH TO FLIGHT PLANNING WILL BE USED 
AS APPROPRIATE 

i ONLY PROFESSIONAL PERSONNEL INCLUDED IN RESOURCES ESTIMATES 


n 
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The flow chart on the right shows the steps necessary to establish the requirements 
for composite resources to support joint pref light activities. 


Having defined 25 joint preflight activities, the next step was to determine the 
general sequence of activity which begins at two years prior to launch. 


Next, the organizational elements or functional groups required to conduct the var- 
ious activities were identified and each of the 25 activities was allocated to one of 
the functions for primary responsibility and to the various functions for support, inputs 
and/or review. 


The modified study trafflG model shown in the Continuation Phase Study Plan was 
used as the model to determine the number of payloads of each type to be flown each year 
from T980 through 1 991 . 


The 25 activities were timelined, based on estimated times required for the initial 
planning activity cycles ranging from least complex to the most complex payloads of each 
class. Based on this data, experience factors were then estimated for repeat flights 
after the first, third and tenth flight of a given category. 


The final steps involve overlaying activity spans for all flights of a given type 
for each year on a month to month timeline. From this data, the joint resources can 
then be established. 
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FLOW FOR JOINT 
FLIGHT PREPARATION 

This chart depicts the general flow of Joint STS-Payload activities and tasks in pre- 
paration for flight as follows: 

a. The Joint Program/ Pro jiect Engineering Functions are the imittal activity with 
development of the Joint Project Plan, It includes task assignments, schedules, 
and development, if Joint Flight Requirements and Flight Operations Data Base 
that constitute key inputs to the other activities shown. 

b. Integrated Flight Planning includes trajectory design, timelines, consumables 
analyses, and subsystems performance analyses. 

c. System Support involves eommuni cations and data handling/proeessing, range and 
network requirements, and software and crew systems analyses. 


The last activities to be completed, since they depend heavily on input from trajec- 
tory design, crew activity timeline and systems analyses which are completed earlier are: 

a. Joint Operations Planning and Procedures Development. This involves integrated 
command, planning, flight rules and flight techniques development and onboard/ 
FGR/POCC procedures and supporting data. 

b. Training and Simulations are accomplished to ready the Joint/ Integrated Crews 
for the flight and verify timelines and procedures. 


As indicated by the dashed arrows, the Joint Operations Planning and Procedures 
Development is an iterative activity with Training and Simulations. 
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ACTIVITY FLOW FOR 
JQNT STS-PAYLOAD 
FLIGHT PREPARATION 
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INVOLVEMENT OF OPERATIONAL 
ELEMENTS IN PREPARATIONS 
FOR FUGHT OPERATIONS 


Thi's Ghart shows the Imvol vement of operational functions as associated with the 25 
preflight activities. "P" designated the functions recommended for primary responsibility. 
“I" indicates those functions which provide major reviews, support and/or inputs. 


The first three function columns indicate functions performed tjy the program offices, 
i.e., STS Program Office, Payload Program Office and Shuttle Payload Integration and 
Development Program Office, (SPIDPO), respectively. SPIDPO logically would be respon** 
si'ble for the majority of program office activities which involve interfaces between the 
STS and payloads, with notable exception of the flight requirements specified by the Pay- 
load Program Offices. 


Within the Payload Operations Centers (POG's), which include JSC, GSFG, and JPL, 
the supporting functions involve Payload Operations Control Centers (POCG's), Payload 
GoordinatOrs (PC’s), Flight Design, Grew Activity Planning, Training and Simulations. 
Gommunications and Data Haindliing and Data Processing. 


The MGC-H (STS Operator) has been recommended as the responsible function for the 
flight and operations planning activities which comprise the majority of Joint pre- 
flight Activities. 


Other functions which support or have inputs to the activities include; Integrated 
Operations Manager (lOM), Network Operations, Launch/Landing Site Interfaces, STS Flight 
Crew, Payload Flight Crew and Mission Manager. 
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FUNCTIONS 

JOINT ACTIVITy"'"'''''"'^^ 
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STS PROJECT OFFICE 

PAYLOAD PROJECT OFFICE 
(INDIVIDUAL OR INTEGRATED) 

[ 
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This chart demonstrates the total manpower resources required for: 

a. A Space! ab 7-Day Flight, 

b. Flight No. 1 of this type flight. 

e. Tasks assoeiated with the System Support Activity, 
d. The time period of 22 months before launch until launch. 

This technique was used in determiining the manpower requirements for each of the 
60 summary worksheets discussed previously. 
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TYRCAL ACTIVITY MANLOADING 
SHOWING COMPARATIVE 
EXPERENCE FACTORS 


This chart shows two of the three experience factors (not shown is the Flight 5 
Experience Factor), which were used as summation worksheets for the composite manpower 
curves for each of 60 activity cases. These 60 Ga!ses provided totals for the five major 
activities, for the four payload categories and three experience factors. 

The procedure followed in estiimating man-loading was to analyze each task and sub- 
task in terms of the efforts to be performed, when they should be perfonned, what func- 
tional organizations and skills were involved, the number of separate Interfaces, 
documentation and/or products to be produced, and the likely availability of input 
material or data from sources outside the joint task performer group. 


This analysis was made on a task by task basis estimating the manpower for each 
payload category starting with the first flight and then proceeding to estimate the 
reduction iin manpower resulting from the experience factors. 
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TYPICAL ACTIVITY MANLOADING 


EXPEFHENCE FACTORS 

SPACELAB PAYLOADS 7-DAY FLIfiHTS. SYSTE1 S0PPOW (1AA2) 


TIME BEFORE 

LAUNCH (L.) 

L-2 YEVWIS 

.24 1 23 1 22 1 21120.1.191 18.1 171 1,6.1 1'S.I 14 1 13. 

' L-1 YEAR 

1:2.1 111 mi 9 1 8 1 7 1 6 1 5. 1 4 1 3. 1 2 ! 1 . 

EXPERIENCE FACTOR: FLIGHT T 


iBB***i 


EXPEM'ENCE FACTOR: FLlGHiT 2 


IM— H Pi 


msmm^ 







This chart illustrates the sequence of the performance of the tasks involved in the 
final step in estimating the Composite Resources. 

These tasks Gonsisted of gaierating: 
a. A Resources Estimating Structure. 

h. Composite Task and Subtask Estimates and Experience Factors for Each Activity 
and Payload Category. 

e. Suiranations of Composite Resources. 
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A Y'esourGes estiimating strueture as shown on the facing chart, was developed to facili- 
tate Gomputirng the composite resources by month and year. 

In addition to the structure shown on this chart additional charts were used to assign 
specific flight number to each of the activities under each flight type. 

The diagrams assigned unique code numbers to Payload Categories, activities, and 
individual flights to organize these elements into a hierarchy for use in computing the 
composite results. 
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This chart is a Summary of Resource Requirements, Flights 1, 2 and 5 for Joint Flight 
Preparation Activities. It provides a summary corapariing the total resource requirements 
for each Joint Activity with respect to each of the three experience factor flights as 
well as with respect to the average for all Payload categories for each experience fac- 
tor flight. 

This chart provides a direct numerical comparison of the difference in resources 
required for Flights 1, 2 and 5, for each joint aevitity and each flight type. The last 
column on this figure provides the average manpower for each activity and each experience 
factor among all the flight types. 

Resources planning personnel can compare the resource requirements for an activity 
within a given flight type with the average for that activity for all flight types. 

The sum of the averages 1m the bottom right hand columns indicates that the average 
resources for all activities and flight types is 15% less for Flight 2 than Flight 1 and 
25% less for Flight 5 than for Flight 2. Flight 5 is 38% less than Flight 1. 


41 
















REQUIREMENTS. 
RJGHTS 1. 2 AND 5 









ACTiIV4!TY 

STS PAYLOAD CATEGORY 1 

AVERAGE FOR ALL 
PAYLOAD CATEGORIES 

SPACELAB 7-DAV 
RIGHTS 

TOTAL HAN-HONTHS 

SPACELAB 30-DAY 
RIGHTS 

TOTAL HAN-HOHTHS 

AEO FLIGHTS 
TOTAL MAN-MOfiTHS 

PLANErARY RIGHTS 
TOTAL HAN-HONTHS 

EXPERIEHCE FACTOR 

EXPERIENCE FACTOR 

EXPERIENCE FfliCTOR 

EWERIENCE FACTOR 

EXPERIENCE FACTOR 

Flight 1 

Flight 2: 

Flight 5 

Flight 1 

Flight 2 

Flight 5 

Flight 1 

Flight 2 

Flight 5 

Flight 1 

Flight 2 

Flight 5 

Flight 1 

Flight 2 

Flight 5 

I 4 Joint pRocfiAM/PROJECT 
Engineering Functions 

lAATOl 

102 

VAAil02 

78 

1AA105 

55 

1AB101 

123 

1AB102 
^ 100 

TAB! 05 
65 

1B101 

99 

1B102 

80 

1BT05 

57 

TCI 01 

90 

1G102 ^ 

71 

1C105 

ST 

104 

32 

57 

2, Syst-EH Support 

lAA2m 

T21 

1AA202 

106 

1AA205 

81 

VAB201 

138 

VAB202 

T15 

1AB2Q5 

92 

1B201 

123 

1B202 

105 

1B205 

84 

1C201 

115 

1C202 

97 

1C205 

81 

124 

106 

85 

3* Integrated Flight 
Planning 

1AA301 

93 

1AA302 

82 

VAA305 

62 

VAB301 

120 

TAB302 

100 

1AB3D5 

81 

1U3Q1 

65 

1B302 

55 

1B305 

38 

IC301 ; 

71 

IL3U2 

58 

1C305 

42 

87 

74 

56 

Ai Joint Operations Plan- 
ning AND Procedures 
Develophent 

rAA4on 

6& 

VAA402 

51 

1AA4Q5 

36 

1AB401 

74 

1AS402 

62 

VAB40S 

45 

1B4D1 

55 

1B4D2 

40 

1B4D5 

29 

TG401 

57 

1C402 

42 

1C405 

30 

63 

49 

35 

5i Training and 

SlHULATIONS 

VAA501 

SO 

TAA502 

29 

1AA506 

28 

IAB501 

SB 

1AB502 

47 

I'AOSOB 

36 

1B5D1 

22 

1B502 

18 

1B505 , 

15 

1C501 

23 

1C502 

18 

1G505 

15 

39 

31 

24 

Sw, All Activities Per 
Flight 

431 

355 

252 

513 

1 

i 

424 

319 

365 

298 

223 

356 

286 

219 

4i; 

342 

257 


41a 


' ■■ -ivSi*' I *-'V' 'iX ’ : J( ■ J/ii'il ft i»> ^:V' '' 1 ' ■■ t ‘ ^ ■ ' 1. - f ■• ‘V i->iJ 'W ; ; - i ■ - ■' i ► :.■ ■■ ■ ■ - L ' 1 = , - 




:^^iiiiSti'. H^Vt-«i-'j iojj.Li ^ 





This chart shows the relative manpower for each activity by month and year as 
well as the direct comparison between support requirements for each activity. 

An iindtcati'On of the rate of build up of resources required for each activity 
and the relationship of the starting times for each of the activities is immediately 
obvious from observation of these curves. 


It will be noted that human resources for training and simulations are not 
required until 10 months later than activation of the activities for Joint Program/ 
Project Engineering Functions. 
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This Ghart showing Total ResourGes for All Flight Types and All AGtivities indi Gates 
a fairly linear build up in the total professional manpower resourees required for all 
preflight planning, training and simulations aGtivities beginning in 1978 and extending 
through 1985 An analysis of the curve from 1979 which is the first full year of 
activities through 1983 reveals the following with regard to total resources required: 

a. The total manpower resources required over the five year span is 17,809 man 
months . 

b* The average number of professional personnel required during this period for 
joint activities is about 300 per year. 

G. The average rate of increase im personnel from year to year over this four 
year period is 110 personnel per year. 

The dashed portion of the curve provides a gross estimate of the growth rate of 
manpower for th '984 and 1985 period. This dashed curve is an extrapolation of the 
solid curve based on an average growth of flight types per year. 
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TOTAL RESOUFICES 
ALL FLIGHT TYPES 

ALL ACTIVITIES 







This chart depicts the major conclusions derived from this study consisting of: 

a* The overriding factor which produced these conclusions -las the fact that each 
selected center had much more previous experience and existing capability 
with respect to its assigned pay load responsibility than any other NASA Center. 


The prime factors influencing the decisions for backup support were: 

1. GSFC backup Space! ab Payloads because ©f similarity of experience with 
unmanned Earth Orbiting Payloads. 

2. JSC backup Automated Earth Orbiting Payloads because of similarity of 
experience with manned Earth Orbiting and Lunar experiments. 

3. JPL backup both AEO and Spacelab Payloads in a limited fashion because of 
its experience in Payload control and related support. 


c. Rather than each center developing a unique approach to its suipport of STS- 
Pay loads, much can be done to coordinate real-time flight control procedures, 
implementation of activities in preapration for STS flights and in standardiz- 
ing operational interfaces among the various STS operating elements, through 
a coordinated effort to bring these activities together. 
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OVERALL STUDY CONCLUSIONS 



• BASED ON THE SURVEY OF GAPABILITIES OF SEVEN NASA CENTERS^ IT WAS 

CONCLUDED THAT INITIAL CENTER RESPONSIBILITY FOR STS PAYLOAD 
MISSION CONTROL SWOULD LOGICALLY BE ASSIGNED TO: 

- JSC FOR SPAGELAB PAYLOADS 

- 6SFC FOR AUTOMATED EARTH ORBITING PAYLOADS 

- JiPL FOR PLANETARY PAYLOADS 

• AS A RESULT OF INVESTIGATIONS OF POGC AND SYSTEM STANDARDIZATION, IT WAS CONGLUDED 

THAT A REASONABLE LEVEL OF PAYLOAD FLIGHT CONTROL STANDARIDZATION DICTATES 
AN ULTIMATE CAPABILITY FOR: 

- JSC AND 6SFG TO HANDLE SPACELAB PAYLOADS 

-* GSFC AND JSC TO HANDLE AUTOMATED EARTH ORBITING PAYLOADS 

- JiPL TO HANDLE PLANETARY PAYLOADS WITH A BACKUP CAPABILITY TO 

HANDLE SPACELAB AND AEO PAYLOADS 

t STUDY OF EXISTING AND PLANNED CAPABILITIES OF NASA CENTERS FOR PAYLOAD 
FLIGHT CONTROL REVEALS A NEED FOR STANDARDIZATION AND INCREASED COM- 
PATIBILITY AMONG THE CENTERS IN THE AREAS OF: 

- RiEAL-TIME FLIGHT CONTROL RESOURCES AND PROCEDURlES 

- IMPLEMENTATION OF ACTIVITIES IN PREPARATION FOR STS FLIGHT 

OPERATIONS 

- INTERFACES BETWEEN POGC'S AND STS OPERATIONAL ELEMENTS 
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d. The foTTowing ground rules and assumptions should be used with respect to de- 
fining a Data Base Management System. 

1- The Gommuni cation Processors at each site should be compatible to allow 
for standardization of computer- to-computer operation and simplify soft- 
ware design. 

2. A Payload Operation Center communication processor should be the focal 
point of distribution for all Data Bases residing at that Center. 

3. JPL and AF/STC do not share Experiment Data Bases with other Centers. 

KSC is assumed to have the Launch Processing System (LPS) Data Base and 
VAFB will also utilize it for WTR launches and landings, as well as 
having a supplemental data base at VAFB. 

5. The MGG-H (STS Operator) contains all STS/Payload Operations Data Bases 
even though they may be housed in JSC facilities. 

6. The Center's support to POCG's resides in the Center's computer facili- 
ties, and POCC/PI Common Data Bases are assumed to reside in the POG 
computer facility. 


e. An evolutionary approach to art integrated, standardized multi-center system 
for STS-Payload Flight Control can build toward an ultimate capability to 
support the full traffic model with minimum expenditures. A final system 
architecture which uses the existing Gapabilities initially and expands the 
capability just ahead of the growth in requirements can be iimplemented. An 
integrated NASA-wide system will permit pooling resources and will eliminate 
need less redundancy, thus reducing cost. 


f. A key decision which should be made as early as possible is that of expanding 
the initial capabilities of GSFG/JSC/JPL Payload Operations Control Centers 
or adding additional Centers to accommodate increasing loads as the flight 
traffic model increases. This decision will affect the architecture of the 
ultimate system and the methods of achieving a full capability. The manner 
in which users will interface with payload operations will also be affected. 
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• A NASA-WIDE SUPERVISORY DATA BASE MANAGEMENT SYSTEM FOR STS-.PAYLOA0S 

WILL; 

- ENHANCE DATA TRANSFER AMONG OPERATIONAL ELEMENTS 

- MINIMIZE MAINTENANCE OF REDUNDANT DATA BASES 

- REDUCE THE SIZE OF THE INDIVIDUAL CENTERS DATA BASE MANAGEMENT 

SYSTEM 

- HELP INSURE THE CURRENCY OF GPERATIONAL DATA 

a AN EVOLUTIONARY APPROACH TO SYSTEM ENHANCEMENT UTILIZING THE THREE 

SYSTEM CONCEPTS DERIVED IN THE STUDY^ IS THE MOST EFFICIENT WAY TO 
DEVELOP THE ULTIMATE CAPABILITY FOR SUPPORT OF THE STS-PAYLOAD 
TRAFFIC MODEL. 

- SIMPLIFIED OPERATIONAL TEAH STRUCTURES 

- STREAMLINED COMMAND AND CONTROL CONCEPTS 

- POCC STANDARDIZATION 

- ECONGMIGAL WIDEBAND COMMUNICATIONS VIA DOMSATS 

- STANDARD PORTABLE POCC'S 

• IN ORDER TO SUPPORT THE STS -PAYLOAD FLIGHT TRAFFIC MODEL^ BEGINNING 

WITH PRESENT NASA CAPABILITIES^ IT WILL BE NECESSARY TO IMPLEMENT THE 
FEATURES OF THE THREE SYSTEM CONCEPTS AND STANDARD POCC CONCEPT BY 
MID-I982. 
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STUDY RECOMMENDATIONS 


An early program is needed to establish standards for payload design so that stan- 
dardization of ground operating equipment and software can be achieved.. Standardization 
can start by utilizing the best of all presently existing capabilities of the various 
Centers. Ultinmtely, a set of standards for communications and data handling from which 
users can select one or more formats from a "menu" would facilitate the use of proeess- 
ing firmware on the ground and permit simplification of procedures, documentation, train- 
ing and ether aspects of system support. 


The ultimate system should optimize standardization of POCC's for all payloads to 
the extent practicable. Standardization can extend to much of the system software, 
will promote system versatility for support of various payloads and will facilitate 
fast turn-around from one flight to another. Spares, maintenanGe and other logistics 
functions will be simplified through optimized standardization. 


The achievement of standardization should begin by adopting the best of existing 
resources and extending their use to the other Centers. As existing systems become 
obsolete and reach the end of their normal life cycle, new resources, optimized to 
meet the ultimate requirement, can be phased into the system. 


In order to determine composite requirements for resources for the STS Operator 
tasks in long range planning, it is recommended that the same methodology be used as 
in this study task. This would maximize the probability of identifying areas of 
overlap or gaps in planning activities between the joint operation planners and the 
unique STS Operator planning.. 


• STANDARDIZATION ~ STANDARDIZATION - STANDARDIZATION 

- PAYLOAD GOMMUNICATIONS AND DATA HANDLING 

- POCC'S 

- DATA MANAGEMENT 

- OPERATIONAL PROGEDURES 

- PREFLIGMT PLANNING^ TRAINING AND SIMULATION METHODS 
“ OPERATING INTERFACES 

• REGOMMEND TIMELY IMPLEMENTATION OF THE STANDARD POGG GONGEPT AND 

THE AGCOMPANYIN6 SYSTEM ENHANCEMENT TO INSURE THE ULTIMATE CAPABILITY 
REQUIRED BY THE TRAFFIC MODEL 

• ACGOMPL I SH STANDARDIZATION BY MAINTAINING THE BEST EXISTING OR PLANNED 

CAPABILITIES OF EACH CENTER AS A BASIS FOR EXPANSION 

• UTILIZE STUDY METHODOLOGY TO DETERMINE RESOURCES REQUIRED OF THE STS 

OPERATOR. THIS WILL ASSIST IN IDENTIFYING ANY GAPS OR OVERLAPS IN 
THE ACTIVITIES AND TASKS. 
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In order to quantify the system effectiveness of limited standardization for “ 

POCC's as a cost savings measure, a cost analysis of the concept should be performed. ® 

This cost analysis will develop the specific areas of cost advantage which will point ^ 

to programs which should be undertaken to develop the most beneficial standardization 
features. 


As is always the case, manpower is the major resource required for STS-Payload 
Operations. Consequently, any steps which can be taken to reduce manpower can 
result In significant savings. Some of the potential areas to explore for these 
savings are listed on the facing page. 


Now that the major areas of resource expenditure nave been identified for pre- 
flight planning activities, it may be appropriate to examine some of these joint f; 

activities as candidate areas to include in the user charge allocations. 

a I 

The use of mini-computers will enhance system simplicity and ease of modulari- 
zation of system software. , 
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STUDY RECOMMENDATIONS 

tCONTINUED) 


t A COST ANALYSIS O'F THE STANDARD POGC NETWORK DEVELOPMENT CONCEPT 
SHOULD BE UNDERTAKEN TO QUANTIFY THE COST OF IMPLEMENTATION AND 
THE SAVINGS WHICH WOULD ACCRUE DURING THE STS OPERATIONAL ERA. 

§ SINCE MANPOWER IS THE MAJOR RIESOURCE IN OPERATIONAL PLANNING^ RESOURCES 
SHOULD BE CONSERVED THROUGH ; 

- AUTOMATION 

- ELIMINATION OF REDUNDANCY 

- CENTRALIZED FUNCTIONAL CAPABILITIES FOR SIMILAR EFFORTS 

- PRODUCTION LINE TECHNIQUES FOR REPETITIVE ACTIVITIES 

- USE OiF STANDARD MOiDULES - FOR FLIGHT PLANNING 

- CROSS-TRAINING BETWEEN SPECIALIZED PERFORMER GROUPS. 

§ IT IS RECOMMENDED THAT THE RESO'URCES ESTIMATES FOR THE JOINT PREFLIGHT 
PREPARATION ACTIVITIES BE ASSESSED FOR IMPACT ON THE USER CHARGE 
ALLOCATIONS. 

• EXPLOIT THE USE OF MIN I -COMPUTERS TO SIMPLIFY AND MODULARIZE THE 
SYSTEM, 
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